Atari Mega Archive 1/Atari Mega Archive - Volume 1.iso/lists/mint/l_1199/823

Internet Message Format | 1994-08-27 | 4.0 KB

Date: Mon, 17 Jan 1994 13:30:23 +0100
From: Christian Lynbech <[e-mail]>
Message-Id: <[e-mail]>
To: [e-mail]
In-Reply-To: <[e-mail]> ([e-mail])
Subject: Re: [MINTOS] fs tree structure  (was: Re: MiNT goes UNiX, ... )


> Annius Groenink writes:
>
> > > I'd like to propose not to go into too much detail in defining a "standard"
> > > for the file system layout.  Different distributions will handle things
> > > differently, so I don't see much sense in discussing at this time where
> > > particular binaries of particular flavours of Unix should live, especially
> > > since most programs are independent of their physical location.
> >
> > I totally agree.  MiNT shouldn't be viewed as an attempt to obtain a
> > complete UNIX clone.  I mean look at this discussion, it's ridiculous,
> > really.  There's nothing Atari-specific left.  What about GEM for example.
> > Did we forget about that?
>
> (I think you've missed the point.)

Perhaps I did.

> I didn't want to ask everybody to stop discussing how MiNT could be
> turned into something that looks like Unix.  I just proposed not to
> commit ourselves to a fixed Unix tree structure (i.e., where the
> binaries live, etc.) because I think that it should be the task of a
> distribution kit to set things up.  People could then choose a
> distribution that matches their preferences.

Yes, but is it realistic for us to work on several different setups?

My vision of this whole project is that we work toward some collected
notion of a UNIX-like system. Ideally in the form of a distribution
kit, complete with all necessary stuff, but even just some documents
containing standards would do the trick. How detailed such a standard
should be, is open for discussion.

Personally, I believe we need to choose between BSD and SYSV style fs
layout, and this implies syaing things like /bin,/var,.... Also, I
think we should consider where to put the C subsystem (include and
libraries)

The whole point is to keep everybody from having to configure/compile
sources themeselves. There are currently many binaries on
atari.archive, but you can never be sure about what setup the binaries
have been compiled with (dare I mention tcsh again :-).

> Rather, we should concentrate on things that have to be generalized
> in order to reach a state where Unix software con be compiled out of
> the box.

Yes, but equivally important is to ensure that there are in fact
a collected system. We should feel obligated to keep uploading systems
conforming to whatever conventions we decide on, so that you can
always say: "just download <such-and-such>, these binaries conform to
the <whatever> standard".

> As far as GEM and Atari specifics are concerned, it would be nice to
> have them fit into a Unix environment nicely.  With the current GEM
> implemtations, this seems to be impossible.  What we're in need
> of is a GEM server (that can be killed and replaced by an X server :-)
> or, even better, a set of GEM widgets on the top of X.

We certainly need a GEM server. This could provide the necessary
critical regions around the actual calls into the ROMs, and adding
socket based communication, one should even get some sense of remote
sessions.

This GEM could then evolve into an X server, giving up on precise X
appearance in return of being able to reuse the code in GEM.
Hopefully, the result would be a more lightweight system than a
fullblown X server. In principle, one could also hack up a GEM-based
Xlib clone, but judging from the number of routines in Xlib, I think
the other thing is easier.

Just dreaming along,

------------------------------------------------------------------------------
Christian Lynbech               | Hit the philistines three times over the
office: R0.33 (phone: 3217)    | head with the Elisp reference manual.
email: [e-mail]    |        - [e-mail] (Michael A. Petonic)
------------------------------------------------------------------------------